G,Self-imposed deadlines,Need for solution already validated,Version control as documentation tool,Informal user testing,Light-weight software design,Manual testing,Unit tests,Agile Development,Continuous development,Iterative development,Digital task tracking,Minimal low-level project management,Adaptable work procedures,Speed rather than correct development tools,Clear responsibilities,Wiki as a documentation tool,Homogenized code,56,48,18,Documented project plan,Consumer interest verified cheaply and quickly before starting development work,No need for formal communication when a small team of <=5 is co-located,Existing business model from Gulleggið participation,This version based on an earlier design by one of the founders,No need for formal planning meetings for a small team of <=5,Occasional organizational meetings,No formal user testing,6 month app development period,A lot of indirect user testing from acquaintances,Continuous Development,Iterative development,Focus on team proficiency speed for choice of prototype development tools,6 week prototyping period,Features/functionality initially designed visually on a marker-board,Features/functionality designs mocked up in HTML/CSS,Initial usage of Jira has ceased,Data structure designed/visualized on a marker board as needed,Work plan/schedule based on self-imposed deadlines for features,Lesson learnt: Better defined milestones might have increased effectiveness of project,Web services unit tested,Expected results and project parts loosely defined.,Automated tests would have been a waste of time for this project,Sufficiently detailed plan readable as a Gantt chart or excel document,Team was experienced in various work methodologies and picked procedures as they saw fit for the team and the project,Lesson learnt: More thought on decision of development environment might have sped up work,Loose easily adjusted working methods better than formal work procedures in a uncertain environment,Product previews to others sparked ideas,Version control with code change history and reasoning/explanation in commit messages,Continuous development meant priority on fixing faults,Faults noticed as soon as they break builds,Uncertainty of innovation leads to uncertainty of process,No documentation of code structure or design,More important to solve issues/implement functionality quickly than correctly when innovating,Team used coding standards and linters to homogenize and increase code quality.,Relying on enough usage testing to find majority of usage bugs,Work focussed to an extent on putting out fires and building bridges,Lack of prototype design slowed down development work,Short reminders better than a structured system for a team of <=5,No low level sub-part planning for project,Loose rapidly adjustable process effective in developing for three platforms,Task tracking in Asana,Clear division of responsibilities,Founding team not formed around a specific business opportunity,No integration testing,Tasks tracked with tickets to some extent,Project info stored in a Wiki website,Started with a plan with defined milestones,Minimal automated testing,Lesson learnt: Choice of technology within team capabilities increased initial success but reduces chances of on-boarding staff with existing experience.,Agile development,Occasional stand-up meetings,Work on every software development stage at the same time – not a Waterfall model,All testing performed in-house,Founding team had a clear idea of how far along they wanted to be with the project when they‘d receive outside investment,Work proceeded fast in great part due to synchronization of team,Initial service implemented over email – quick&cheap way to validate that the product would be used
